Optimisation of a compiler generated program code

ABSTRACT

In a method for the optimisation of compiler-generated program code, the compiler-generated program code is searched for program code fragments which correspond, at least in their effect, to respectively one library code fragment contained in a predefined library. The program code fragments found thereby are replaced by respectively one call of the corresponding library code fragment. A computer program product comprises program instructions for the execution of this method. A portable data carrier contains both the program code optimised according to this method and the library.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The invention relates to the programming of portable data carriers andto the execution of programs by portable data carriers. A portable datacarrier within the meaning of the present document may be, inparticular, a chip card (smart card), in various designs, or a chipmodule.

2. Description of the Related Art

Portable data carriers, as they are in common use today, have aprocessor core and a plurality of memories produced in differenttechnologies. In a typical configuration, for example, a mask-programmedROM, an electrically erasable and programmable EEPROM and a writeableRAM are provided. The RAM serves as a working memory during the runningof the program, while the program code to be executed by the processorcore can be stored in the ROM and/or in the EEPROM. These and similardesigns of data carriers are described in section 3.4 of the book“Handbuch der Chipkarten” by W. Rankl and W. Effing, Hanser Verlag,third edition 1999.

Typically, a memory cell in the EEPROM occupies approximately four timesthe chip area of a ROM memory cell. In order to save chip area, or toachieve greater available memory capacity with the same area, it istherefore desirable for the executable program code to be accommodatedas extensively as possible in the ROM. However, it is necessary that thecontent of the mask-programmed ROM is unalterably defined for largenumbers of data carriers as early as during the production stage of themask-programmed ROM. Writing into the EEPROM, by contrast, is performedonly upon the completion and initialisation of a series of datacarriers, or when the individual data carriers are personalised. Due tothe greater flexibility, therefore, it is advantageous for theexecutable program code to be stored as extensively as possible in theEEPROM. This applies both to the programming of smaller productionvolumes of data carriers and to the correction of faults and theintroduction of additional functions in the case of large-volumeproduction.

SUMMARY OF THE INVENTION

In the programming of portable carriers, there is therefore the problemof, on the one hand, using the mask-programmed ROM or a comparablememory as extensively as possible and, on the other hand, achieving asgreat a flexibility as possible for program changes and/or for theproduction of data carriers in smaller production volumes.

According to the invention, the above problem is solved, wholly orpartially, by a method for optimizing compiler-generated program codeintended for a portable data carrier having both a processor core and afirst and second memory area, the first memory area being provided toreceive the optimized program code, the second memory area beingprovided to receive a predefined library having a multiplicity oflibrary code fragments, and the compiler-generated program code beingsearched for program code fragments which correspond, at least inrespect of their effect, to respectively one library code fragment, theprogram code fragments found thereby being replaced by respectively onecall of the corresponding library code fragment.

Further according to the invention, the above problem is solved, whollyor partially, by a computer program product comprising programinstructions for a general-purpose computer which cause thegeneral-purpose computer to optimize compiler-generated program codeintended for a portable data carrier having both a processor core and afirst and second memory area, the first memory area being provided toreceive the optimized program code, the second memory area beingprovided to receive a predefined library having a multiplicity oflibrary code fragments, and the compiler-generated program code beingsearched for program code fragments which correspond, at least inrespect of their effect, to respectively one library code fragment, theprogram code fragments found thereby being replaced by respectively onecall of the corresponding library code fragment.

Further according to the invention, the above problem is solved, whollyor partially, by a portable data carrier having a processor core, afirst memory area and a second memory area, there being contained in thefirst memory area optimized program code, and there being contained inthe second memory area a library which is predefined independently ofthe optimized program code and has a multiplicity of library codefragments, wherein the optimized program code has been obtained fromcompiler-generated program code by searching for program code fragmentswhich correspond, at least in respect of their effect, to respectivelyone library code fragment, the program code fragments found therebybeing replaced by respectively one call of the corresponding librarycode fragment.

The sequence in which the steps are itemised in the claims relating tothe method is not to be understood as a limitation of the extent ofprotection. Rather, developments of the invention are provided for inwhich these steps are performed in a different sequence, or wholly orpartially in parallel, or wholly or partially interleaved with oneanother.

The invention proceeds from the basic idea of using a predefined librarycontaining a multiplicity of library code fragments for the purpose ofoptimizing the program code. In the optimization method according to theinvention, the program code to be optimized, for its part, is searchedfor program code fragments which correspond in their effect or functionto respectively one library code fragment. Such program code fragmentsare replaced by respectively one call of the corresponding library codefragment. The optimized program code is stored in a first memory area ofthe data carrier (e.g., in the EEPROM), while the library is providedfor storage in a second memory area (e.g., in the ROM).

In tests performed by the inventors, the optimization procedureaccording to the invention resulted in a marked reduction of the size ofthe program code provided for the first memory area. This result isunexpected, since one would intuitively assume that, with a library ofrealistic extent, only few parts of the program code would be found tocorrespond to the library code fragments.

The reduction of the code size brought about by the invention has theresult that, in the case of a data carrier with a predefined amount ofmemory, program code for additional functions can be included in thefirst memory area. If the first memory area is designed as an EEPROM orin a comparable technology, this program code need only be loaded uponthe completion or initialisation or personalisation of the data carrier.The program code which, due to its compactness, implements amultiplicity of functions, can therefore be changed or newly writtenboth rapidly and even for small production volumes of data carriers, oreven for single data carriers.

According to the invention, the predefined library is located in thesecond memory area, i.e., for example, in the mask-programmed ROM.Normally, the saving of program code achieved by the optimizationaccording to the invention is less than the size of the library. Even inthis case, however, the application of the invention is advantageous,due to the better utilisation of the valuable first memory area. If inthe compiler-generated program code there are many code fragments,groups of which in each case can be replaced by respectively one singlecode fragment of the library, and if the library contains only few codefragments which are not required, the optimization can result in theprogram code shrinking by even more than the length of the library. Inthis case, use of the invention is advantageous even if the first andsecond memory areas are only conceptual sections of one and the samephysical memory field.

According to the invention, for the purpose of optimization a search isperformed for program code fragments, i.e., for sections in thecompiler-generated program code which can be replaced by correspondinglibrary code fragments. This subsequent optimization procedure need notbe taken into account by the programmer during program generation; inparticular, the programmer need not make provision in the program forcalls of library routines. Thus, programming is not in any way renderedmore difficult by the invention.

In the choice of words used here, the terms “program code” or “codefragment” are intended to denote both executable machine code, before orafter linkage, and the corresponding assembler source code. In otherwords, in different developments of the invention the optimizationprocedure according to the invention can be performed both on the basisof the compiler-generated assembler source code and on the basis of thealready assembled machine code. In the case of the former, theassembling and, if necessary, the linkage are performed only afteroptimization. The library, likewise, can be available duringoptimization as assembler source code and/or as already assembledmachine code.

In general, a replacement of a program code fragment by a library codefragment is possible whenever both code fragments perform mutuallycorresponding functions. In this connection, complex calculations can beperformed in respect of the exact effects of code fragments in order,for example, to initiate a replacement procedure even if individualinstructions in the code fragments are commuted in an innocuous manner.In particularly simple exemplary embodiments, by contrast, a replacementis performed only if the code fragments are identical in respect of themachine code defined by them. Even in the case of this simpledevelopment, however, a certain analysis of the code fragments isrequired, due to the fact that, for example, a code fragment having ajump with a jump destination which is not in the code fragment may notgenerally be replaced.

Additional replacement possibilities ensue if parameterised codefragments are used which, in a manner similar to a procedure call,contain one or more parameters (e.g., memory addresses or numericalvalues).

Preferably, a library code fragment is normally called through asubroutine call instruction inserted in the program code. A returninstruction, immediately following the library code fragment, is thenprovided in the library. Exceptions from this rule may apply in someembodiments if the code fragment to be replaced interferes with theprogram flow. If, for example, the code fragment ends with a subroutinereturn instruction, the call can normally be effected by means of a jumpinstruction.

According to the invention, the library used is predefined, i.e., notdependent on the program code processed in the current optimization run.In order to achieve the best possible optimization results, however, thelibrary is preferably designed so that it contains appropriate entriesfor frequently occurring structures of the program code. Such frequentlyoccurring code sections may depend, in particular, on the hardwareand/or an operating system of the data carrier and/or on a compiler usedin the generation of the compiler-generated program code.

The computer program product provided according to the invention may be,in particular, a computer-readable data carrier such as, for example, anelectronic or magnetic or optical memory medium, but it is not limitedto physical data carriers. Electrical or optical signals (e.g., voltagelevels of a communication link) are also to be understood as computerprogram product in the sense used here. The computer program productcontains program code which executes the optimization steps according tothe invention. Preferably, the computer program product additionallyincludes a compiler and/or an assembler and/or a linker and/or a loaderprogram.

The computer program product according to the invention and the portabledata carrier according to the invention are preferably developed withfeatures which correspond to the features described above and/or statedin the claims relating to the method.

BRIEF DESCRIPTION OF THE DRAWINGS

Further features, objects and advantages of the invention are disclosedby the following description of an exemplary embodiment and a pluralityof alternative embodiments.

Reference is made to the schematic drawing, in which the sole FIGURE(FIG. 1) shows a representation of a portable data carrier and ofdifferent versions of the program code in an exemplary embodiment of theinvention.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

The invention is used in the programming of a portable data carrier 10which, in the exemplary embodiment described here, is designed as a chipcard. The data carrier 10 contains, in a manner known per se, asemiconductor chip having a processor core 12, a mask-programmed ROM 14,an EEPROM 16, a RAM 18, and an interface 20 for contactless orcontact-bound communication. The said components are connected to oneanother via a bus 22. In alternative embodiments, the three memoryfields 14, 16, 18 may be designed in other technologies; in particular,FLASH technology may be used for the ROM 14 and/or the EEPROM 16.

A first and a second memory area 24, 26 are conceptually provided in thememory fields 14, 16, 18. The first memory area 24 serves to receive theoptimized program code in the form of executable machine code. Apredefined library 28, likewise in the form of executable machine code,is stored in the second memory area 26. In the exemplary embodimentdescribed here, the first memory area 24 is located in the EEPROM 16,and the second memory area 26 is located in the ROM 14. In a mannerknown per se, the ROM 14 contains, in addition to the second memory area26, further, fixedly predefined routines which constitute, for example,an operating system of the data carrier 10. The EEPROM 16 additionallyincludes a file system for data which are to be stored as non-volatiledata in the data carrier 10.

The library 28 has a multiplicity of predefined library code fragments30A, 30B, 30C, . . . , which are denoted generally in the following by30 x. In FIG. 1, for reasons of clearer representation, the library codefragments 30 x are shown as assembler source code. Normally, eachlibrary code fragment 30 x is followed immediately by a subroutinereturn instruction 32A, 32B, . . . (denoted generally in the followingby 32 x). The subroutine return instruction 32 x may be omitted,however, if it cannot be reached in the execution of the library codefragment 30 x due to the fact that, for example, each program flow ofthe library code fragment 30 x ends in an exit or in a subroutine returninstruction contained in the library code fragment 30 x.

The program development for the portable data carrier 10 proceeds from ahigh-level language source code 34, which is represented exemplarily inFIG. 1 in the programming language C. The section shown in FIG. 1 waitsuntil the third bit of the input register INPORT out from the unitposition attains the value “0”, and then sets the output registerOUTPORT to the hexadecimal value “FF”. A compiler 36 known per seconverts the high-level language source code 34 into compiler-generatedprogram code 38, which in FIG. 1 is represented in the form of assemblersource code for the 6805 instruction set. Other instruction sets,respectively in accordance with the processor core 12, are provided forin alternative embodiments.

An optimization program 40 executes the optimization steps that areessential for the present exemplary embodiment. The optimization program40 processes the compiler-generated program code 38 and, moreover,accesses information about the library code fragments 30 x contained inthe library 28. In different embodiment variants, this information cancontain, for example, a copy of the library 28 in the assembler sourcecode and/or a copy of the library 28 in the executable machine codeand/or a specification of the effect of the individual library codefragments 30 x in an appropriate description language. Furthermore,additional information such as, for example, indexes or hash tables canbe provided in order to accelerate the search procedures performed bythe optimization program 40.

The optimization program 40 identifies program code fragments 42contained in the compiler-generated program code 38 which, in executionby the processor core 12, have a function which is identical to that oflibrary code fragments 30 x contained in the library 28. Used for thispurpose in the present exemplary embodiment is a relatively simpleprocedure, in which the compiler-generated program code 38 is compared,at assembler source text level, with the individual entries in thelibrary 28. With regard to the instructions in short form and theaddress and value information, a textual comparison can be performed inthis case. Symbolic jump destinations, by contrast, must be converted,prior to comparison, into a standardised form or into a numeric relativevalue. In alternative embodiments, by contrast, the optimization can beperformed on the basis of a compiler-generated program code 38 alreadypresent in the form of assembled machine code.

A program code fragment 42 for which a corresponding library codefragment 30 x has been found in the comparison procedure is replaced, inthe optimization procedure, by a call of this library code fragment 30x. In FIG. 1, for example, the program code fragment 42 and the librarycode fragment 30B are identical apart from the symbolic designation ofthe jump destination. In the optimized program code 44, therefore, theoptimization program 40 replaces this program code fragment 42 by a callof the library code fragment 30B. In the present example, this call isdesigned as a subroutine call instruction 46. Since, in the presentexample, the program code fragment 42 corresponds to a machine code ofseven bytes in length and the subroutine call instruction 46 requiresonly three bytes, the memory space required for the optimized programcode 44 has been substantially reduced by the replacement.

Following completion of the optimization, the optimized program code 44is converted by an assembler 48 into machine code that can be executedby the processor core 12. Following a possibly necessary linkingoperation with further program parts, the code is loaded into the firstmemory area 24 upon completion or initialisation or personalisation ofthe data carrier 10. The library 28 has already been present in thesecond memory area 26 since the time at which the chip for the datacarrier 10 was produced. The data carrier 10 is therefore ready for use.The translation, optimization and assembling steps described above areperformed by a general-purpose computer (not shown in FIG. 1) whichexecutes the compiler 36, the optimization program 40 and the assembler48.

When, in the operation of the data carrier 10, the program execution bythe processor core 12 reaches the location of the subroutine callinstruction 46 in the first memory area 24, the library code fragment30B in the second memory area 26 is executed as a subroutine. In theireffect, the executed instructions correspond exactly to the program codefragment 42 removed during the optimization. Following execution ofthese instructions, the processor core 12 executes a return, triggeredby the subroutine return command 32B, to that instruction in the firstmemory area 24 which immediately follows the subroutine call instruction46.

It must be ensured during the optimization that the program functionsare not altered. Thus, for example, program code fragments 42 havingjump instructions which might have a jump destination located outsidethe program code fragment 42 should only be replaced following preciseanalysis. A replacement is allowable if each possible flow of theprogram code fragment 42 ends with an exit or a subroutine return. Insuch cases, however, the corresponding library code fragment 30 x iscalled by means of a normal jump instruction rather than by means of asubroutine call instruction. These considerations may also be includedeven at the time of generation of the library 28, so that the lattercontains only such library code fragments 30 x that may be used withoutfurther constraints.

The library 28 should be of such construction that it providesappropriate library code fragments 30 x as often as possible and thusoffers as may optimization possibilities as possible. Thus, for example,the library code fragment 30B of FIG. 1 is matched to the hardwarecharacteristics of the data carrier 10. If the input bit requested inthis library code fragment 30B corresponds to a frequently requiredsignal value, it is to be assumed that corresponding program codefragments 42 occur time and again in the compiler-generated program code38 even for greatly differing applications of the data carrier 10.Similarly, frequent operating system calls can be covered bycorresponding library code fragments 30 x. A further source forrepeating code fragments in the compiler-generated program code 38results from the fact that the code generation in the compiler 36 isperformed according to certain schemas, and recurring code structuresare generated as a consequence.

Overall, therefore, it is advantageous, for the purpose of generatingthe library 28, to statistically evaluate the program code 38 generatedby the compiler 36 for a multiplicity of applications designated for thehardware and the operating system of the data carrier 10.

The particulars contained in the above description of sample embodimentsshould not be construed as limitations of the scope of the invention,but rather as exemplifications of preferred embodiments thereof.Accordingly, the scope of the invention should be determined not by theembodiments illustrated, but by the appended claims and their legalequivalents.

1. A method for optimising compiler-generated program code intended fora portable data carrier having a processor core and a first and secondmemory area, comprising: the first memory area being provided to receivethe optimised program code, the second memory area being provided toreceive a predefined library having a multiplicity of library codefragments, wherein the contents of the predefined library have beendetermined independently from the compiler-generated program code thatis to be optimized, and the compiler-generated program code beingsearched for program code fragments that perform the same function as arespective one of the library code fragments, the program code fragmentsfound thereby being replaced by respectively one call of thecorresponding library code fragment.
 2. The method according to claim 1,wherein a program code fragment is replaced by a library code fragmentonly if both code fragments are identical in their form as executablemachine code.
 3. The method according to claim 1, wherein at least somelibrary code fragments are parameterised.
 4. The method according toclaim 1, wherein a program code fragment to be replaced is replaced, atleast if the program code fragment does not interfere with the programflow, by a subroutine call instruction to the corresponding library codefragment.
 5. The method according to claim 1, wherein thecompiler-generated program code exists in the form of assembler sourcecode, and the optimization procedure is performed on a source codelevel.
 6. The method according to claim 1, wherein the predefinedlibrary is matched to at least one of the following: the hardware of theportable data carrier, an operating system of the portable data carrier,and a compiler used in the generation of the compiler-generated programcode.
 7. The method according to claim 1, wherein the first memory areais electrically programmable.
 8. The method according to claim 1,wherein the second memory area is mask-programmable.
 9. The methodaccording to claim 1, wherein the first memory area occupies more chiparea per memory cell in the portable data carrier than is occupied bythe second memory area.
 10. A computer program product comprising acomputer-readable storage medium and program instructions for ageneral-purpose computer stored in the computer-readable storage medium,the program instructions causing the general-purpose computer tooptimize compiler-generated program code intended for a portable datacarrier having both a processor and a first and second memory area, thefirst memory area being provided to receive the optimized program code,the second memory area being provided to receive a predefined libraryhaving a multiplicity of library code fragments, wherein the contents ofthe predefined library have been determined independently from thecompiler-generated program code that is to be optimized, and theoptimization includes searching the compiler-generated program code forprogram code fragments that perform the same function as a respectiveone of the library code fragments, the program code fragments foundthereby being replaced by respectively one call of the correspondinglibrary code fragment.
 11. The computer program product according toclaim 10, wherein the program instructions additionally implement acompiler for converting a high-level language source code into thecompiler-generated program code.
 12. The computer program productaccording to claim 10, wherein a program code fragment is replaced by alibrary code fragment only if both code fragments are identical in theirform as executable machine code.
 13. The computer program productaccording to claim 10, wherein a program code fragment to be replaced isreplaced, at least if the program code fragment does not interfere withthe program flow, by a subroutine call instruction to the correspondinglibrary code fragment.
 14. The computer program product according toclaim 10, wherein the compiler-generated program code exists in the formof assembler source code, and the optimization procedure is performed ona source code level.
 15. The computer program product according to claim10, wherein the predefined library is matched to at least one of thefollowing: the hardware of the portable data carrier, an operatingsystem of the portable data carrier, and a compiler used in thegeneration of the compiler-generated program code.
 16. The computerprogram product according to claim 10, wherein the first memory area iselectrically programmable, and the second memory area ismask-programmable, and the first memory area occupies more chip area permemory cell in the portable data carrier than is occupied by the secondmemory area.
 17. A portable data carrier having a processor, a firstmemory area and a second memory area, there being contained in the firstmemory area optimized program code, and there being contained in thesecond memory area a library which is predefined independently of theoptimized program code and has a multiplicity of library code fragments,wherein the contents of the predefined library have been determinedindependently from the compiler-generated program code that is to beoptimized, and wherein the optimized program code has been obtained fromcompiler-generated program code by searching for program code fragmentsthat perform the same function as a respective one of the library codefragments, the program code fragments found thereby being replaced byrespectively one call of the corresponding library code fragment. 18.The portable data carrier according to claim 17, wherein, when obtainingthe optimized program code from the compiler-generated program code, aprogram code fragment is replaced by a library code fragment only ifboth code fragments are identical in their form as executable machinecode.
 19. The portable data carrier according to claim 17, wherein thepredefined library is matched to at least one of the following: thehardware of the portable data carrier, an operating system of theportable data carrier, and a compiler used in the generation of thecompiler-generated program code.
 20. The portable data carrier accordingto claim 17, wherein the first memory area is electrically programmable,and the second memory area is mask-programmable, and the first memoryarea occupies more chip area per memory cell in the portable datacarrier than is occupied by the second memory area.
 21. The computerprogram product according to claim 10, wherein the first memory areaoccupies more chip area per memory cell in the portable data carrierthan is occupied by the second memory area.
 22. The portable datacarrier according to claim 17, wherein the first memory area occupiesmore chip area per memory cell in the portable data carrier than isoccupied by the second memory area.